The issue does not have yet an CVE number assigned.
From 07bc500d45f781a7e2915afb7eebc2d6d9a541c9 Mon Sep 17 00:00:00 2001
From: Dirk Farin <dirk.farin@gmail.com>
Date: Wed, 2 Sep 2026 23:55:01 +0200
Subject: [PATCH] Fix heap-use-after-free in decoder_context::reset()
(GHSA-mm7m-v26f-wf8x)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
decoder_context::reset() calls dpb.clear() which frees all de265_image objects
and their owned slice_segment_header structs. However, reset() never nulls the
previous_slice_header pointer, leaving a dangling reference into freed memory.
When the next NAL unit after reset() is a dependent slice, slice_segment_header::read()
at slice.cc:435 executes:
*this = *ctx->previous_slice_header;
This copies from freed 1464-byte struct — heap-use-after-free (CWE-416).
The in-stream case was already guarded by commit 12ba88ec (decctx.cc:556 nulls
previous_slice_header on first slice of new picture). This fix applies the same
invariant to the reset() path: only a slice header still retained by a live image
may remain as previous_slice_header.
Origin: https://github.com/strukturag/libde265/commit/eb346780796055d9f9aac62d725d3170aa60c7b4
Bug: https://github.com/strukturag/libde265/security/advisories/GHSA-xp3h-6f5r-8cxp
Comment: As the version in bookworm does not have StatCoeff_models, those
patch parts have been omitted.
Concurrent Execution using Shared Resource with Imprope
Synchronization ('Race Condition') and Use After Free and Double Free in
libde265.
There is no CVE assigned yet.
From eb346780796055d9f9aac62d725d3170aa60c7b4 Mon Sep 17 00:00:00 2001
From: Dirk Farin <dirk.farin@gmail.com>
Date: Wed, 2 Sep 2026 20:09:20 +0200
Subject: [PATCH] Fix WPP CABAC context handoff race (GHSA-xp3h-6f5r-8cxp)
In WPP-threaded decoding, each CTB row task hands its saved CABAC
context (imgunit->ctx_models[row]) to the row below through
context_model_table, a hand-rolled refcounted handle whose model and
refcnt pointers are mutated together by copy, assignment, release(),
and decouple(). The producer/consumer handoff relied on
wait_for_progress()/set_progress() to order the accesses, but that
lock's fast path read a plain non-atomic int with no acquire/release
barrier, so writes to a row slot were not reliably published across
threads. Under a crafted stream this let two tasks touch the same
slot's ownership metadata concurrently, corrupting it and causing
heap-use-after-free / double-free (confirmed via AddressSanitizer,
reproducing the double-free in context_model_table::release() at
the exact reported sites).
Add a mutex to image_unit guarding the whole copy/release (consumer)
and assign/decouple (producer) sequence for a row slot, so ownership
transitions are mutually exclusive. Also make de265_progress_lock's
progress counter atomic with acquire/release ordering, closing the
underlying missing-barrier gap that the same fast path exposes to
every other wait_for_progress() consumer (deblocking, SAO, motion
readiness).
Verified: unpatched build reliably double-frees under ASan within a
few hundred fuzzer iterations; the fixed build stayed clean across
thousands of iterations of the same reproducers. Decode output is
unchanged (girlshy.h265 hash matches single- and multi-threaded).
The image pixel accessors computed xpos + ypos*stride in signed 32-bit
arithmetic; frames with width*height > INT32_MAX wrap the offset and the
returned pointer lands far outside the buffer (OOB read/write). Widen
stride/offset math to 64 bits and store validated SPS dimensions in
uint16_t.
Large SPS dimensions with 16-bit bit depth overflow the 32-bit allocation
size in de265_image_get_buffer(); the wrapped ~1 KB allocation is later
written with the full plane size, corrupting the heap.
CVE-2026-49337: free orphaned slice header when no active image unit
Origin: upstream, https://github.com/strukturag/libde265/commit/683cb9fa603e35840642f98765ab95cdb71cadf9
Bug: https://github.com/strukturag/libde265/security/advisories/GHSA-g5hj-rf9f-7vxm
Bug-Debian: https://bugs.debian.org/1140431
Applied-Upstream: 1.1.0
Comment: Backport: on 1.0.15 the pre-existing unconditional add_slice_segment_header() call must be removed (upstream moves it into the guarded block); keeping both would double-free every slice header.
Slice headers attached to finished pictures without an active image unit
were retained forever; a crafted NAL sequence can grow memory without
bound during continuous streaming.
Missing aggregate bound check on predicted reference picture set entries
allows exceeding the 16-entry array, an out-of-bounds array write in
process_reference_picture_set().
as the version in bookworm is still using SDL1.2, the resize() function has
been backported for SDL1.2.
The display444as420() does not need backporting, as with SDL1.2 the faulty
pointer arimethic is not needed, SDL has separate buffers.
From 4089de0845e0009e019be4ca5cbebaf2aee0a8ce Mon Sep 17 00:00:00 2001
From: Dirk Farin <dirk.farin@gmail.com>
Date: Sun, 10 May 2026 22:37:53 +0200
Subject: [PATCH] dec265: fix SDL OOB on 4:4:4 streams and mid-stream
resolution change (closes #460)
Tobias Frost [Fri, 13 Jan 2023 11:22:45 +0000 (12:22 +0100)]
[PATCH] Don't update sps if they are only repeated
This is an attempt to improve the mitigations from #365 and #366 and picks up an idea I described at #345:
> One way would be just to look at the pointers of the SPS (fast and easy, but
> may reject more than required), or investigate if the SPS used for the image
> generations are "compatible".
This changes do exactly this: It (very conservativly) checks if the old and new sps have
identical information -- except the reference picture set, which I believe is supposed
to be updated by new sps'). If they are basically identical, the old sps will be
used instead of the new one, (of course, reference image set is updated from the new one)
I'm using standalone operator== and helper functions to avoid changing ABI of the library;
if an ABI bump would be done, of course this should go to the respective classes.
Tobias Frost [Mon, 12 Dec 2022 13:33:40 +0000 (14:33 +0100)]
[PATCH] Use the sps from the image
(as e.g mc_chroma is using the sps to determine
picture properties, like pic_width_in_luma_samples
and pic_height_in_luma_samples, I *think* this is
more correct.
This PR is for discussion. (See #345.)
It makes the failures go away, but that does not mean it's correct :)
The following poc will be stop failing if (only) this
patch is applied:
The following are still failing if only this patch is
applied, but they stop failing if #365 is applied as well, but will
still fail with ONLY #365 applied (IOW, both are needed)
projects / libde265.git / log